SQLAlchemy ORM ಸಂಬಂಧ ಮ್ಯಾಪಿಂಗ್: ಲೇಜಿ vs. ಈಗರ್ ಲೋಡಿಂಗ್ ಕುರಿತು ಒಂದು ಆಳವಾದ ವಿಶ್ಲೇಷಣೆ

ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಜಗತ್ತಿನಲ್ಲಿ, ನಾವು ಬರೆಯುವ ಆಬ್ಜೆಕ್ಟ್-ಆಧಾರಿತ ಕೋಡ್ ಮತ್ತು ನಮ್ಮ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ರಿಲೇಷನಲ್ ಡೇಟಾಬೇಸ್‌ಗಳ ನಡುವಿನ ಸೇತುವೆಯು ಒಂದು ನಿರ್ಣಾಯಕ ಕಾರ್ಯಕ್ಷಮತೆಯ ಜಂಕ್ಷನ್ ಆಗಿದೆ. ಪೈಥಾನ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ, SQLAlchemy ಒಂದು ಶಕ್ತಿಶಾಲಿಯಾಗಿ ನಿಂತಿದೆ, ಇದು ಒಂದು ಶಕ್ತಿಯುತ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಆಬ್ಜೆಕ್ಟ್-ರಿಲೇಷನಲ್ ಮ್ಯಾಪರ್ (ORM) ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು ಡೇಟಾಬೇಸ್ ಟೇಬಲ್‌ಗಳೊಂದಿಗೆ ಸರಳ ಪೈಥಾನ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಂತೆ ಸಂವಹನ ನಡೆಸಲು ನಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಹೆಚ್ಚಿನ ಕಚ್ಚಾ SQL ಅನ್ನು ಅಮೂರ್ತಗೊಳಿಸುತ್ತದೆ.

ಆದರೆ ಈ ಅನುಕೂಲವು ಒಂದು ಗಂಭೀರ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಬರುತ್ತದೆ: ನೀವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ನ ಸಂಬಂಧಿತ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಿದಾಗ—ಉದಾಹರಣೆಗೆ, ಲೇಖಕರು ಬರೆದ ಪುಸ್ತಕಗಳು ಅಥವಾ ಗ್ರಾಹಕರು ಮಾಡಿದ ಆರ್ಡರ್‌ಗಳು—ಆ ಡೇಟಾವನ್ನು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಹೇಗೆ ಮತ್ತು ಯಾವಾಗ ತರಲಾಗುತ್ತದೆ? ಉತ್ತರವು SQLAlchemyಯ ಸಂಬಂಧ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳಲ್ಲಿದೆ. ಇವುಗಳ ನಡುವಿನ ಆಯ್ಕೆಯು ಮಿಂಚಿನ ವೇಗದ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಅರ್ಥೈಸಬಲ್ಲದು.

ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿಯು ಡೇಟಾ ಲೋಡಿಂಗ್‌ನ ಎರಡು ಪ್ರಮುಖ ತತ್ವಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ: ಲೇಜಿ ಲೋಡಿಂಗ್ (Lazy Loading) ಮತ್ತು ಈಗರ್ ಲೋಡಿಂಗ್ (Eager Loading). ಲೇಜಿ ಲೋಡಿಂಗ್‌ನಿಂದ ಉಂಟಾಗಬಹುದಾದ ಕುಖ್ಯಾತ "N+1 ಸಮಸ್ಯೆಯನ್ನು" ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ ಮತ್ತು SQLAlchemy ಒದಗಿಸುವ ವಿವಿಧ ಈಗರ್ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳಾದ—joinedload, selectinload, ಮತ್ತು subqueryload—ಬಗ್ಗೆ ಆಳವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಕೊನೆಯಲ್ಲಿ, ನೀವು ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ಉತ್ತಮ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಹೆಚ್ಚು ಕಾರ್ಯಕ್ಷಮತೆಯುಳ್ಳ ಡೇಟಾಬೇಸ್ ಕೋಡ್ ಬರೆಯಲು ಜ್ಞಾನವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.

ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆ: ಲೇಜಿ ಲೋಡಿಂಗ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ನೀವು SQLAlchemyಯಲ್ಲಿ ಸಂಬಂಧವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದಾಗ, ಅದು "ಲೇಜಿ ಲೋಡಿಂಗ್" ಎಂಬ ತಂತ್ರವನ್ನು ಬಳಸುತ್ತದೆ. ಈ ಹೆಸರು ಸ್ವತಃ ವಿವರಣಾತ್ಮಕವಾಗಿದೆ: ORM 'ಸೋಮಾರಿ'ಯಾಗಿರುತ್ತದೆ ಮತ್ತು ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಕೇಳುವವರೆಗೂ ಯಾವುದೇ ಸಂಬಂಧಿತ ಡೇಟಾವನ್ನು ತರುವುದಿಲ್ಲ.

ಲೇಜಿ ಲೋಡಿಂಗ್ ಎಂದರೇನು?

ಲೇಜಿ ಲೋಡಿಂಗ್, ನಿರ್ದಿಷ್ಟವಾಗಿ select ತಂತ್ರ, ಸಂಬಂಧಿತ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಲೋಡಿಂಗ್ ಅನ್ನು ಮುಂದೂಡುತ್ತದೆ. ನೀವು ಮೊದಲು ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಾಗಿ (ಉದಾಹರಣೆಗೆ, Author) ಪ್ರಶ್ನಿಸಿದಾಗ, SQLAlchemy ಆ ಲೇಖಕರ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಹಿಂಪಡೆಯುತ್ತದೆ. ಸಂಬಂಧಿತ ಸಂಗ್ರಹ (ಉದಾಹರಣೆಗೆ, ಲೇಖಕರ books) ಹಾಗೆಯೇ ಉಳಿಯುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಮೊದಲು author.books ಆಟ್ರಿಬ್ಯೂಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಮಾತ್ರ SQLAlchemy ಎಚ್ಚೆತ್ತುಕೊಂಡು, ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕ ಸಾಧಿಸಿ, ಸಂಬಂಧಿತ ಪುಸ್ತಕಗಳನ್ನು ತರಲು ಹೊಸ SQL ಕ್ವೆರಿಯನ್ನು ನೀಡುತ್ತದೆ.

ಇದನ್ನು ಬಹು-ಸಂಪುಟದ ವಿಶ್ವಕೋಶವನ್ನು ಆರ್ಡರ್ ಮಾಡಿದಂತೆ ಯೋಚಿಸಿ. ಲೇಜಿ ಲೋಡಿಂಗ್‌ನೊಂದಿಗೆ, ನೀವು ಆರಂಭದಲ್ಲಿ ಮೊದಲ ಸಂಪುಟವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ. ನೀವು ಅದನ್ನು ತೆರೆಯಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಮಾತ್ರ ಎರಡನೇ ಸಂಪುಟವನ್ನು ವಿನಂತಿಸಿ ಮತ್ತು ಸ್ವೀಕರಿಸುತ್ತೀರಿ.

ಅಡಗಿರುವ ಅಪಾಯ: "N+1 ಸೆಲೆಕ್ಟ್ಸ್" ಸಮಸ್ಯೆ

ನಿಮಗೆ ಸಂಬಂಧಿತ ಡೇಟಾ ಅಪರೂಪವಾಗಿ ಬೇಕಾಗಿದ್ದರೆ ಲೇಜಿ ಲೋಡಿಂಗ್ ಸಮರ್ಥವಾಗಿದ್ದರೂ, ಇದು N+1 ಸೆಲೆಕ್ಟ್ಸ್ ಸಮಸ್ಯೆ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಒಂದು ಕುಖ್ಯಾತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಪಾಯವನ್ನು ಹೊಂದಿದೆ. ಈ ಸಮಸ್ಯೆಯು ನೀವು ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಸಂಗ್ರಹದ ಮೇಲೆ ಪುನರಾವರ್ತನೆ ಮಾಡುವಾಗ ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಲೇಜಿ-ಲೋಡೆಡ್ ಆಟ್ರಿಬ್ಯೂಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸಿದಾಗ ಉದ್ಭವಿಸುತ್ತದೆ.

ಒಂದು ಶ್ರೇಷ್ಠ ಉದಾಹರಣೆಯೊಂದಿಗೆ ಇದನ್ನು ವಿವರಿಸೋಣ: ಎಲ್ಲಾ ಲೇಖಕರನ್ನು ತರುವುದು ಮತ್ತು ಅವರ ಪುಸ್ತಕಗಳ ಶೀರ್ಷಿಕೆಗಳನ್ನು ಮುದ್ರಿಸುವುದು.

1. ನೀವು N ಲೇಖಕರನ್ನು ತರಲು ಒಂದು ಕ್ವೆರಿಯನ್ನು ನೀಡುತ್ತೀರಿ. (1 ಕ್ವೆರಿ)
2. ನಂತರ ನೀವು ನಿಮ್ಮ ಪೈಥಾನ್ ಕೋಡ್‌ನಲ್ಲಿ ಈ N ಲೇಖಕರ ಮೂಲಕ ಲೂಪ್ ಮಾಡುತ್ತೀರಿ.
3. ಲೂಪ್‌ನ ಒಳಗೆ, ಮೊದಲ ಲೇಖಕರಿಗಾಗಿ, ನೀವು author.books ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತೀರಿ. SQLAlchemy ಆ ನಿರ್ದಿಷ್ಟ ಲೇಖಕರ ಪುಸ್ತಕಗಳನ್ನು ತರಲು ಹೊಸ ಕ್ವೆರಿಯನ್ನು ನೀಡುತ್ತದೆ.
4. ಎರಡನೇ ಲೇಖಕರಿಗಾಗಿ, ನೀವು ಮತ್ತೆ author.books ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತೀರಿ. SQLAlchemy ಎರಡನೇ ಲೇಖಕರ ಪುಸ್ತಕಗಳಿಗಾಗಿ ಮತ್ತೊಂದು ಕ್ವೆರಿಯನ್ನು ನೀಡುತ್ತದೆ.
5. ಇದು ಎಲ್ಲಾ N ಲೇಖಕರಿಗೆ ಮುಂದುವರಿಯುತ್ತದೆ. (N ಕ್ವೆರಿಗಳು)

ಫಲಿತಾಂಶ? ಒಟ್ಟು 1 + N ಕ್ವೆರಿಗಳನ್ನು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ನೀವು 100 ಲೇಖಕರನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು 101 ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ ರೌಂಡ್ ಟ್ರಿಪ್‌ಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದೀರಿ! ಇದು ಗಮನಾರ್ಹ ಲೇಟೆನ್ಸಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಮೇಲೆ ಅನಗತ್ಯ ಒತ್ತಡವನ್ನು ಹೇರುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತೀವ್ರವಾಗಿ ಕುಗ್ಗಿಸುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಲೇಜಿ ಲೋಡಿಂಗ್ ಉದಾಹರಣೆ

ಇದನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ನೋಡೋಣ. ಮೊದಲು, ನಾವು ನಮ್ಮ ಮಾಡೆಲ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ:

            
from sqlalchemy import create_engine, Column, Integer, String, ForeignKey
from sqlalchemy.orm import sessionmaker, declarative_base, relationship

Base = declarative_base()

class Author(Base):
    __tablename__ = 'authors'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    # This relationship defaults to lazy='select'
    books = relationship("Book", back_populates="author")

class Book(Base):
    __tablename__ = 'books'
    id = Column(Integer, primary_key=True)
    title = Column(String)
    author_id = Column(Integer, ForeignKey('authors.id'))
    author = relationship("Author", back_populates="books")

# Setup engine and session (use echo=True to see generated SQL)
engine = create_engine('sqlite:///:memory:', echo=True)
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine)
session = Session()

# ... (code to add some authors and books)

            

              
                Copy
              
            
          

ಈಗ, N+1 ಸಮಸ್ಯೆಯನ್ನು ಪ್ರಚೋದಿಸೋಣ:

            
# 1. Fetch all authors (1 query)
print("--- Fetching Authors ---")
authors = session.query(Author).all()

# 2. Loop and access books for each author (N queries)
print("--- Accessing Books for Each Author ---")
for author in authors:
    # This line triggers a new SELECT query for each author!
    book_titles = [book.title for book in author.books]
    print(f"{author.name}'s books: {book_titles}")

            

              
                Copy
              
            
          

ನೀವು ಈ ಕೋಡ್ ಅನ್ನು echo=True ನೊಂದಿಗೆ ಚಲಾಯಿಸಿದರೆ, ನಿಮ್ಮ ಲಾಗ್‌ಗಳಲ್ಲಿ ಈ ಕೆಳಗಿನ ಮಾದರಿಯನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ:

            
--- Fetching Authors ---
SELECT authors.id AS authors_id, authors.name AS authors_name FROM authors

--- Accessing Books for Each Author ---
SELECT books.id AS books_id, ... FROM books WHERE ? = books.author_id
SELECT books.id AS books_id, ... FROM books WHERE ? = books.author_id
SELECT books.id AS books_id, ... FROM books WHERE ? = books.author_id
...

            

              
                Copy
              
            
          

ಲೇಜಿ ಲೋಡಿಂಗ್ ಯಾವಾಗ ಉತ್ತಮ ಉಪಾಯ?

N+1 ಅಪಾಯದ ಹೊರತಾಗಿಯೂ, ಲೇಜಿ ಲೋಡಿಂಗ್ ಮೂಲಭೂತವಾಗಿ ಕೆಟ್ಟದ್ದಲ್ಲ. ಸರಿಯಾಗಿ ಅನ್ವಯಿಸಿದಾಗ ಇದು ಉಪಯುಕ್ತ ಸಾಧನವಾಗಿದೆ:

• ಐಚ್ಛಿಕ ಡೇಟಾ: ಸಂಬಂಧಿತ ಡೇಟಾ ಕೇವಲ ನಿರ್ದಿಷ್ಟ, ಅಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಬೇಕಾದಾಗ. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವುದು ಆದರೆ ಅವರು ನಿರ್ದಿಷ್ಟ "ಇತಿಹಾಸ ವೀಕ್ಷಿಸಿ" ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ಅವರ ವಿವರವಾದ ಚಟುವಟಿಕೆಯ ಲಾಗ್ ಅನ್ನು ತರುವುದು.
• ಏಕ ಆಬ್ಜೆಕ್ಟ್ ಸಂದರ್ಭ: ನೀವು ಸಂಗ್ರಹದೊಂದಿಗೆ ಅಲ್ಲ, ಒಂದೇ ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ. ಒಬ್ಬ ಬಳಕೆದಾರರನ್ನು ಹಿಂಪಡೆದು ನಂತರ ಅವರ ವಿಳಾಸಗಳನ್ನು (`user.addresses`) ಪ್ರವೇಶಿಸುವುದು ಕೇವಲ ಒಂದು ಹೆಚ್ಚುವರಿ ಕ್ವೆರಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿರುತ್ತದೆ.

ಪರಿಹಾರ: ಈಗರ್ ಲೋಡಿಂಗ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು

ಈಗರ್ ಲೋಡಿಂಗ್ ಎಂಬುದು ಲೇಜಿ ಲೋಡಿಂಗ್‌ಗೆ ಪೂರ್ವಭಾವಿ ಪರ್ಯಾಯವಾಗಿದೆ. ಇದು SQLAlchemy ಗೆ ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್(ಗಳ) ಜೊತೆಗೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಸಂಬಂಧಿತ ಡೇಟಾವನ್ನು ತರಲು ಸೂಚಿಸುತ್ತದೆ, ಹೆಚ್ಚು ಸಮರ್ಥವಾದ ಕ್ವೆರಿ ತಂತ್ರವನ್ನು ಬಳಸಿ. ಇದರ ಪ್ರಾಥಮಿಕ ಉದ್ದೇಶವು N+1 ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸುವುದಾಗಿದೆ, ಕ್ವೆರಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸಣ್ಣ, ನಿರೀಕ್ಷಿತ ಸಂಖ್ಯೆಗೆ (ಸಾಮಾನ್ಯವಾಗಿ ಕೇವಲ ಒಂದು ಅಥವಾ ಎರಡು) ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ.

SQLAlchemy ಹಲವಾರು ಶಕ್ತಿಯುತ ಈಗರ್ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇವನ್ನು ಕ್ವೆರಿ ಆಯ್ಕೆಗಳನ್ನು ಬಳಸಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ. ನಾವು ಪ್ರಮುಖವಾದವುಗಳನ್ನು ಅನ್ವೇಷಿಸೋಣ.

ತಂತ್ರ 1: joined ಲೋಡಿಂಗ್

ಜಾಯಿನ್ಡ್ ಲೋಡಿಂಗ್ ಬಹುಶಃ ಅತ್ಯಂತ ಸಹಜವಾದ ಈಗರ್ ಲೋಡಿಂಗ್ ತಂತ್ರವಾಗಿದೆ. ಇದು SQLAlchemy ಗೆ SQL JOIN (ನಿರ್ದಿಷ್ಟವಾಗಿ, LEFT OUTER JOIN) ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪೋಷಕ ಮತ್ತು ಅದರ ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಚೈಲ್ಡ್‌ಗಳನ್ನು ಒಂದೇ, ಬೃಹತ್ ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿಯಲ್ಲಿ ಹಿಂಪಡೆಯಲು ಹೇಳುತ್ತದೆ.

• ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಇದು ಪೋಷಕ ಮತ್ತು ಚೈಲ್ಡ್ ಟೇಬಲ್‌ಗಳ ಕಾಲಮ್‌ಗಳನ್ನು ಒಂದೇ ವಿಶಾಲ ಫಲಿತಾಂಶದ ಸೆಟ್‌ನಲ್ಲಿ ಸಂಯೋಜಿಸುತ್ತದೆ. ನಂತರ SQLAlchemy ಪೈಥಾನ್‌ನಲ್ಲಿ ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಚತುರವಾಗಿ ಡಿ-ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಚೈಲ್ಡ್ ಸಂಗ್ರಹಗಳನ್ನು ತುಂಬುತ್ತದೆ.
• ಇದನ್ನು ಹೇಗೆ ಬಳಸುವುದು: joinedload ಕ್ವೆರಿ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ.

            
from sqlalchemy.orm import joinedload

# Fetch all authors and their books in a single query
authors = session.query(Author).options(joinedload(Author.books)).all()

for author in authors:
    # No new query is triggered here!
    book_titles = [book.title for book in author.books]
    print(f"{author.name}'s books: {book_titles}")

            

              
                Copy
              
            
          

ರಚಿಸಲಾದ SQL ಈ ರೀತಿ ಕಾಣಿಸುತ್ತದೆ:

            
SELECT authors.id, authors.name, books.id, books.title, books.author_id 
FROM authors LEFT OUTER JOIN books ON authors.id = books.author_id

            

              
                Copy
              
            
          

`joinedload` ನ ಅನುಕೂಲಗಳು:

• ಏಕ ಡೇಟಾಬೇಸ್ ರೌಂಡ್ ಟ್ರಿಪ್: ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಒಂದೇ ಬಾರಿಗೆ ತರಲಾಗುತ್ತದೆ, ನೆಟ್‌ವರ್ಕ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ಅತ್ಯಂತ ಸಮರ್ಥ: ಮೆನಿ-ಟು-ಒನ್ ಅಥವಾ ಒನ್-ಟು-ಒನ್ ಸಂಬಂಧಗಳಿಗೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ವೇಗದ ಆಯ್ಕೆಯಾಗಿದೆ.

`joinedload` ನ ಅನಾನುಕೂಲಗಳು:

• ಕಾರ್ಟೇಶಿಯನ್ ಪ್ರಾಡಕ್ಟ್: ಒನ್-ಟು-ಮೆನಿ ಸಂಬಂಧಗಳಿಗೆ, ಇದು ಪುನರಾವರ್ತಿತ ಡೇಟಾಗೆ ಕಾರಣವಾಗಬಹುದು. ಒಬ್ಬ ಲೇಖಕರಿಗೆ 20 ಪುಸ್ತಕಗಳಿದ್ದರೆ, ಲೇಖಕರ ಡೇಟಾ (ಹೆಸರು, ಐಡಿ, ಇತ್ಯಾದಿ) ಡೇಟಾಬೇಸ್‌ನಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕಳುಹಿಸಲಾದ ಫಲಿತಾಂಶ ಸೆಟ್‌ನಲ್ಲಿ 20 ಬಾರಿ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ. ಇದು ಮೆಮೊರಿ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು.
• LIMIT/OFFSET ಜೊತೆಗಿನ ಸಮಸ್ಯೆಗಳು: ಒಂದು ಸಂಗ್ರಹದ ಮೇಲೆ `joinedload` ನೊಂದಿಗೆ ಕ್ವೆರಿಗೆ `limit()` ಅನ್ನು ಅನ್ವಯಿಸುವುದರಿಂದ ಅನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶಗಳು ಉಂಟಾಗಬಹುದು ಏಕೆಂದರೆ ಲಿಮಿಟ್ ಅನ್ನು ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಅಲ್ಲ, ಒಟ್ಟು ಜಾಯಿನ್ ಆದ ಸಾಲುಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.

ತಂತ್ರ 2: selectin ಲೋಡಿಂಗ್ (ಆಧುನಿಕ ಗೋ-ಟು ಆಯ್ಕೆ)

selectin ಲೋಡಿಂಗ್ ಒನ್-ಟು-ಮೆನಿ ಸಂಗ್ರಹಗಳನ್ನು ಲೋಡ್ ಮಾಡಲು ಹೆಚ್ಚು ಆಧುನಿಕ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತಮವಾದ ತಂತ್ರವಾಗಿದೆ. ಇದು ಕ್ವೆರಿ ಸರಳತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ನಡುವೆ ಅತ್ಯುತ್ತಮ ಸಮತೋಲನವನ್ನು ಸಾಧಿಸುತ್ತದೆ, `joinedload` ನ ಪ್ರಮುಖ ನ್ಯೂನತೆಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

• ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಇದು ಎರಡು ಹಂತಗಳಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:
  1. ಮೊದಲಿಗೆ, ಇದು ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ (ಉದಾಹರಣೆಗೆ, `authors`) ಕ್ವೆರಿಯನ್ನು ಚಲಾಯಿಸುತ್ತದೆ.
  2. ನಂತರ, ಇದು ಲೋಡ್ ಮಾಡಲಾದ ಎಲ್ಲಾ ಪೋಷಕರ ಪ್ರಾಥಮಿಕ ಕೀಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಚೈಲ್ಡ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, `books`) ಹೆಚ್ಚು ಸಮರ್ಥವಾದ `WHERE ... IN (...)` ಕ್ಲಾಸ್ ಬಳಸಿ ತರಲು ಎರಡನೇ ಕ್ವೆರಿಯನ್ನು ನೀಡುತ್ತದೆ.
• ಇದನ್ನು ಹೇಗೆ ಬಳಸುವುದು: selectinload ಕ್ವೆರಿ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ.

            
from sqlalchemy.orm import selectinload

# Fetch authors, then fetch all their books in a second query
authors = session.query(Author).options(selectinload(Author.books)).all()

for author in authors:
    # Still no new query per author!
    book_titles = [book.title for book in author.books]
    print(f"{author.name}'s books: {book_titles}")

            

              
                Copy
              
            
          

ಇದು ಎರಡು ಪ್ರತ್ಯೇಕ, ಸ್ವಚ್ಛ SQL ಕ್ವೆರಿಗಳನ್ನು ರಚಿಸುತ್ತದೆ:

            
-- Query 1: Get the parents
SELECT authors.id AS authors_id, authors.name AS authors_name FROM authors

-- Query 2: Get all related children at once
SELECT books.id AS books_id, ... FROM books WHERE books.author_id IN (?, ?, ?, ...)

            

              
                Copy
              
            
          

`selectinload` ನ ಅನುಕೂಲಗಳು:

• ಪುನರಾವರ್ತಿತ ಡೇಟಾ ಇಲ್ಲ: ಇದು ಕಾರ್ಟೇಶಿಯನ್ ಪ್ರಾಡಕ್ಟ್ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತದೆ. ಪೋಷಕ ಮತ್ತು ಚೈಲ್ಡ್ ಡೇಟಾ ಸ್ವಚ್ಛವಾಗಿ ವರ್ಗಾಯಿಸಲ್ಪಡುತ್ತವೆ.
• LIMIT/OFFSET ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಪೋಷಕ ಕ್ವೆರಿ ಪ್ರತ್ಯೇಕವಾಗಿರುವುದರಿಂದ, ನೀವು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ `limit()` ಮತ್ತು `offset()` ಅನ್ನು ಬಳಸಬಹುದು.
• ಸರಳವಾದ SQL: ರಚಿಸಲಾದ ಕ್ವೆರಿಗಳು ಡೇಟಾಬೇಸ್‌ಗೆ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಸಾಮಾನ್ಯವಾಗಿ ಸುಲಭವಾಗಿರುತ್ತವೆ.
• ಅತ್ಯುತ್ತಮ ಸಾಮಾನ್ಯ-ಉದ್ದೇಶದ ಆಯ್ಕೆ: ಹೆಚ್ಚಿನ ಟು-ಮೆನಿ ಸಂಬಂಧಗಳಿಗೆ, ಇದು ಶಿಫಾರಸು ಮಾಡಲಾದ ತಂತ್ರವಾಗಿದೆ.

`selectinload` ನ ಅನಾನುಕೂಲಗಳು:

• ಬಹು ಡೇಟಾಬೇಸ್ ರೌಂಡ್ ಟ್ರಿಪ್‌ಗಳು: ಇದಕ್ಕೆ ಯಾವಾಗಲೂ ಕನಿಷ್ಠ ಎರಡು ಕ್ವೆರಿಗಳು ಬೇಕಾಗುತ್ತವೆ. ಸಮರ್ಥವಾಗಿದ್ದರೂ, ಇದು ತಾಂತ್ರಿಕವಾಗಿ `joinedload` ಗಿಂತ ಹೆಚ್ಚು ರೌಂಡ್ ಟ್ರಿಪ್‌ಗಳನ್ನು ಹೊಂದಿದೆ.
• `IN` ಕ್ಲಾಸ್ ಮಿತಿಗಳು: ಕೆಲವು ಡೇಟಾಬೇಸ್‌ಗಳು `IN` ಕ್ಲಾಸ್‌ನಲ್ಲಿರುವ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಮಿತಿಗಳನ್ನು ಹೊಂದಿವೆ. SQLAlchemy ಇದನ್ನು ನಿಭಾಯಿಸಲು ಸಾಕಷ್ಟು ಬುದ್ಧಿವಂತವಾಗಿದೆ, ಅಗತ್ಯವಿದ್ದರೆ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬಹು ಕ್ವೆರಿಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ, ಆದರೆ ಇದು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ಅಂಶವಾಗಿದೆ.

ತಂತ್ರ 3: subquery ಲೋಡಿಂಗ್

subquery ಲೋಡಿಂಗ್ ಒಂದು ವಿಶೇಷವಾದ ತಂತ್ರವಾಗಿದ್ದು, ಇದು `lazy` ಮತ್ತು `joined` ಲೋಡಿಂಗ್‌ನ ಹೈಬ್ರಿಡ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು `limit()` ಅಥವಾ `offset()` ನೊಂದಿಗೆ `joinedload` ಅನ್ನು ಬಳಸುವ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

• ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಇದು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಒಂದೇ ಕ್ವೆರಿಯಲ್ಲಿ ತರಲು JOIN ಅನ್ನು ಸಹ ಬಳಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಇದು ಮೊದಲು ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ ಕ್ವೆರಿಯನ್ನು (`LIMIT`/`OFFSET` ಸೇರಿದಂತೆ) ಒಂದು ಸಬ್‌ಕ್ವೆರಿಯೊಳಗೆ ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರ ಸಂಬಂಧಿತ ಟೇಬಲ್ ಅನ್ನು ಆ ಸಬ್‌ಕ್ವೆರಿ ಫಲಿತಾಂಶಕ್ಕೆ ಜಾಯಿನ್ ಮಾಡುತ್ತದೆ.
• ಇದನ್ನು ಹೇಗೆ ಬಳಸುವುದು: subqueryload ಕ್ವೆರಿ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ.

            
from sqlalchemy.orm import subqueryload

# Get the first 5 authors and all their books
authors = session.query(Author).options(subqueryload(Author.books)).limit(5).all()

            

              
                Copy
              
            
          

ರಚಿಸಲಾದ SQL ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿರುತ್ತದೆ:

            
SELECT ... 
FROM (SELECT authors.id AS authors_id, authors.name AS authors_name 
      FROM authors LIMIT 5) AS anon_1 
LEFT OUTER JOIN books ON anon_1.authors_id = books.author_id

            

              
                Copy
              
            
          

`subqueryload` ನ ಅನುಕೂಲಗಳು:

• LIMIT/OFFSET ನೊಂದಿಗೆ ಜಾಯಿನ್ ಮಾಡಲು ಸರಿಯಾದ ಮಾರ್ಗ: ಇದು ಜಾಯಿನ್ ಮಾಡುವ ಮೊದಲು ಪೋಷಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ಸರಿಯಾಗಿ ಲಿಮಿಟ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ನಿಮಗೆ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ.
• ಏಕ ಡೇಟಾಬೇಸ್ ರೌಂಡ್ ಟ್ರಿಪ್: `joinedload` ನಂತೆ, ಇದು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಒಂದೇ ಬಾರಿಗೆ ತರುತ್ತದೆ.

`subqueryload` ನ ಅನಾನುಕೂಲಗಳು:

• SQL ಸಂಕೀರ್ಣತೆ: ರಚಿಸಲಾದ SQL ಸಂಕೀರ್ಣವಾಗಿರಬಹುದು, ಮತ್ತು ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯು ವಿವಿಧ ಡೇಟಾಬೇಸ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಬದಲಾಗಬಹುದು.
• ಇನ್ನೂ ಕಾರ್ಟೇಶಿಯನ್ ಪ್ರಾಡಕ್ಟ್ ಹೊಂದಿದೆ: ಇದು ಇನ್ನೂ `joinedload` ನಂತೆಯೇ ಪುನರಾವರ್ತಿತ ಡೇಟಾ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ.

ಹೋಲಿಕೆ ಕೋಷ್ಟಕ: ನಿಮ್ಮ ತಂತ್ರವನ್ನು ಆರಿಸುವುದು

ಯಾವ ಲೋಡಿಂಗ್ ತಂತ್ರವನ್ನು ಬಳಸಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡಲು ಇಲ್ಲಿ ಒಂದು ತ್ವರಿತ ಉಲ್ಲೇಖ ಕೋಷ್ಟಕವಿದೆ.

ಸುಧಾರಿತ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳು

ಪ್ರಾಥಮಿಕ ತಂತ್ರಗಳ ಹೊರತಾಗಿ, SQLAlchemy ಸಂಬಂಧ ಲೋಡಿಂಗ್ ಮೇಲೆ ಇನ್ನಷ್ಟು ಸೂಕ್ಷ್ಮ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ.

raiseload ನೊಂದಿಗೆ ಆಕಸ್ಮಿಕ ಲೇಜಿ ಲೋಡ್‌ಗಳನ್ನು ತಡೆಯುವುದು

SQLAlchemy ಯಲ್ಲಿನ ಅತ್ಯುತ್ತಮ ರಕ್ಷಣಾತ್ಮಕ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾದರಿಗಳಲ್ಲಿ ಒಂದು raiseload ಅನ್ನು ಬಳಸುವುದು. ಈ ತಂತ್ರವು ಲೇಜಿ ಲೋಡಿಂಗ್ ಅನ್ನು ಒಂದು ವಿನಾಯಿತಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಕ್ವೆರಿಯಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಈಗರ್-ಲೋಡ್ ಮಾಡದ ಸಂಬಂಧವನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, SQLAlchemy InvalidRequestError ಅನ್ನು ಎತ್ತುತ್ತದೆ.

            
from sqlalchemy.orm import raiseload

# Query for an author but explicitly forbid lazy-loading of their books
author = session.query(Author).options(raiseload(Author.books)).first()

# This line will now raise an exception, preventing a hidden N+1 query!
print(author.books)

            

              
                Copy
              
            
          

ಇದು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ನಂಬಲಾಗದಷ್ಟು ಉಪಯುಕ್ತವಾಗಿದೆ. ನಿರ್ಣಾಯಕ ಸಂಬಂಧಗಳ ಮೇಲೆ raiseload ಅನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಹೊಂದಿಸುವ ಮೂಲಕ, ನೀವು ಡೆವಲಪರ್‌ಗಳನ್ನು ಅವರ ಡೇಟಾ ಲೋಡಿಂಗ್ ಅಗತ್ಯಗಳ ಬಗ್ಗೆ ಜಾಗೃತರಾಗಿರಲು ಒತ್ತಾಯಿಸುತ್ತೀರಿ, ಉತ್ಪಾದನೆಗೆ N+1 ಸಮಸ್ಯೆಗಳು ಜಾರಿಕೊಳ್ಳುವ ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿವಾರಿಸುತ್ತೀರಿ.

noload ನೊಂದಿಗೆ ಸಂಬಂಧವನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು

ಕೆಲವೊಮ್ಮೆ, ನೀವು ಒಂದು ಸಂಬಂಧವನ್ನು ಎಂದಿಗೂ ಲೋಡ್ ಮಾಡಬಾರದು ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೀರಿ. noload ಆಯ್ಕೆಯು SQLAlchemy ಗೆ ಆಟ್ರಿಬ್ಯೂಟ್ ಅನ್ನು ಖಾಲಿಯಾಗಿ ಬಿಡಲು ಹೇಳುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಖಾಲಿ ಪಟ್ಟಿ ಅಥವಾ None). ಯಾವುದೇ ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿಗಳನ್ನು ಪ್ರಚೋದಿಸದೆ ಔಟ್‌ಪುಟ್‌ನಿಂದ ಕೆಲವು ಕ್ಷೇತ್ರಗಳನ್ನು ಹೊರಗಿಡಲು ಬಯಸುವ ಡೇಟಾ ಸೀರಿಯಲೈಸೇಶನ್‌ಗೆ (ಉದಾಹರಣೆಗೆ, JSON ಗೆ ಪರಿವರ್ತಿಸುವುದು) ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ.

ಡೈನಾಮಿಕ್ ಲೋಡಿಂಗ್‌ನೊಂದಿಗೆ ಬೃಹತ್ ಸಂಗ್ರಹಗಳನ್ನು ನಿಭಾಯಿಸುವುದು

ಒಬ್ಬ ಲೇಖಕ ಸಾವಿರಾರು ಪುಸ್ತಕಗಳನ್ನು ಬರೆದಿದ್ದರೆ ಏನು ಮಾಡುವುದು? `selectinload` ನೊಂದಿಗೆ ಅವೆಲ್ಲವನ್ನೂ ಮೆಮೊರಿಯಲ್ಲಿ ಲೋಡ್ ಮಾಡುವುದು ಅಸಮರ್ಥವಾಗಬಹುದು. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ, SQLAlchemy dynamic ಲೋಡಿಂಗ್ ತಂತ್ರವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದನ್ನು ನೇರವಾಗಿ ಸಂಬಂಧದ ಮೇಲೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ.

            
class Author(Base):
    # ...
    # Use lazy='dynamic' for very large collections
    books = relationship("Book", back_populates="author", lazy='dynamic')

            

              
                Copy
              
            
          

ಪಟ್ಟಿಯನ್ನು ಹಿಂತಿರುಗಿಸುವ ಬದಲು, `lazy='dynamic'` ನೊಂದಿಗೆ ಆಟ್ರಿಬ್ಯೂಟ್ ಒಂದು ಕ್ವೆರಿ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಯಾವುದೇ ಡೇಟಾವನ್ನು ನಿಜವಾಗಿ ಲೋಡ್ ಮಾಡುವ ಮೊದಲು ಹೆಚ್ಚಿನ ಫಿಲ್ಟರಿಂಗ್, ಆರ್ಡರಿಂಗ್ ಅಥವಾ ಪೇಜಿನೇಶನ್ ಅನ್ನು ಚೈನ್ ಮಾಡಲು ಇದು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

            
author = session.query(Author).first()

# author.books is now a query object, not a list
# No books have been loaded yet!

# Count the books without loading them
book_count = author.books.count()

# Get the first 10 books, ordered by title
first_ten_books = author.books.order_by(Book.title).limit(10).all()

            

              
                Copy
              
            
          

ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗದರ್ಶನ ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

1. ಪ್ರೊಫೈಲ್ ಮಾಡಿ, ಊಹಿಸಬೇಡಿ: ಕಾರ್ಯಕ್ಷಮತೆ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನ ಸುವರ್ಣ ನಿಯಮವೆಂದರೆ ಅಳೆಯುವುದು. ರಚಿಸಲಾಗುತ್ತಿರುವ ನಿಖರವಾದ SQL ಕ್ವೆರಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು SQLAlchemy ಯ `echo=True` ಇಂಜಿನ್ ಫ್ಲ್ಯಾಗ್ ಅಥವಾ SQLAlchemy-Debugbar ನಂತಹ ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕ ಸಾಧನವನ್ನು ಬಳಸಿ. ನೀವು ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಅಡಚಣೆಗಳನ್ನು ಗುರುತಿಸಿ.
2. ರಕ್ಷಣಾತ್ಮಕವಾಗಿ ಡೀಫಾಲ್ಟ್ ಮಾಡಿ, ಸ್ಪಷ್ಟವಾಗಿ ಅತಿಕ್ರಮಿಸಿ: ಒಂದು ಉತ್ತಮ ಮಾದರಿಯೆಂದರೆ ನಿಮ್ಮ ಮಾಡೆಲ್ ಮೇಲೆ lazy='raiseload' ನಂತಹ ರಕ್ಷಣಾತ್ಮಕ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಹೊಂದಿಸುವುದು. ಇದು ಪ್ರತಿಯೊಂದು ಕ್ವೆರಿಯು ಅದಕ್ಕೆ ಬೇಕಾದುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. ನಂತರ, ಪ್ರತಿಯೊಂದು ನಿರ್ದಿಷ್ಟ ರೆಪೊಸಿಟರಿ ಫಂಕ್ಷನ್ ಅಥವಾ ಸರ್ವಿಸ್ ಲೇಯರ್ ಮೆಥಡ್‌ನಲ್ಲಿ, ಆ ಬಳಕೆಯ ಪ್ರಕರಣಕ್ಕೆ ಅಗತ್ಯವಿರುವ ನಿಖರವಾದ ಲೋಡಿಂಗ್ ತಂತ್ರವನ್ನು (`selectinload`, `joinedload`, ಇತ್ಯಾದಿ) ನಿರ್ದಿಷ್ಟಪಡಿಸಲು query.options() ಅನ್ನು ಬಳಸಿ.
3. ನಿಮ್ಮ ಲೋಡ್‌ಗಳನ್ನು ಚೈನ್ ಮಾಡಿ: ನೆಸ್ಟೆಡ್ ಸಂಬಂಧಗಳಿಗಾಗಿ (ಉದಾಹರಣೆಗೆ, ಲೇಖಕ, ಅವರ ಪುಸ್ತಕಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಪುಸ್ತಕದ ವಿಮರ್ಶೆಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದು), ನೀವು ನಿಮ್ಮ ಲೋಡರ್ ಆಯ್ಕೆಗಳನ್ನು ಚೈನ್ ಮಾಡಬಹುದು: options(selectinload(Author.books).selectinload(Book.reviews)).
4. ನಿಮ್ಮ ಡೇಟಾವನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ: ಸರಿಯಾದ ಆಯ್ಕೆಯು ಯಾವಾಗಲೂ ನಿಮ್ಮ ಡೇಟಾದ ಆಕಾರ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರವೇಶ ಮಾದರಿಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಇದು ಒನ್-ಟು-ಒನ್ ಅಥವಾ ಒನ್-ಟು-ಮೆನಿ ಸಂಬಂಧವೇ? ಸಂಗ್ರಹಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸಣ್ಣವೇ ಅಥವಾ ದೊಡ್ಡವೇ? ನಿಮಗೆ ಯಾವಾಗಲೂ ಡೇಟಾ ಬೇಕಾಗುವುದೇ, ಅಥವಾ ಕೆಲವೊಮ್ಮೆ ಮಾತ್ರವೇ? ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವುದು ನಿಮ್ಮನ್ನು ಅತ್ಯುತ್ತಮ ತಂತ್ರದತ್ತ ಮಾರ್ಗದರ್ಶಿಸುತ್ತದೆ.

ತೀರ್ಮಾನ: ಅನನುಭವಿಯಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರೊ ವರೆಗೆ

SQLAlchemy ಯ ಸಂಬಂಧ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳನ್ನು ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವುದು ದೃಢವಾದ, ಸ್ಕೇಲೆಬಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಯಾವುದೇ ಡೆವಲಪರ್‌ಗೆ ಒಂದು ಮೂಲಭೂತ ಕೌಶಲ್ಯವಾಗಿದೆ. ನಾವು ಡೀಫಾಲ್ಟ್ `lazy='select'` ಮತ್ತು ಅದರ ಅಡಗಿದ N+1 ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಪಾಯದಿಂದ `selectinload` ಮತ್ತು `joinedload` ನಂತಹ ಈಗರ್ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳು ನೀಡುವ ಶಕ್ತಿಯುತ, ಸ್ಪಷ್ಟ ನಿಯಂತ್ರಣಕ್ಕೆ ಪ್ರಯಾಣಿಸಿದ್ದೇವೆ.

ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಇದು: ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿರಿ. ಕಾರ್ಯಕ್ಷಮತೆ ಮುಖ್ಯವಾದಾಗ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಗಳನ್ನು ಅವಲಂಬಿಸಬೇಡಿ. ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಕಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಯಾವ ಡೇಟಾ ಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ ಮತ್ತು ಆ ಡೇಟಾವನ್ನು ಅತ್ಯಂತ ಸಮರ್ಥ ರೀತಿಯಲ್ಲಿ ನಿಖರವಾಗಿ ತರಲು ನಿಮ್ಮ ಕ್ವೆರಿಗಳನ್ನು ಬರೆಯಿರಿ. ಈ ಲೋಡಿಂಗ್ ತಂತ್ರಗಳನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ, ನೀವು ಕೇವಲ ORM ಅನ್ನು ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದನ್ನು ಮೀರಿ; ನೀವು ಅದನ್ನು ನಿಮಗಾಗಿ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುತ್ತೀರಿ, ಕೇವಲ ಕ್ರಿಯಾತ್ಮಕವಲ್ಲದೆ, ಅಸಾಧಾರಣವಾಗಿ ವೇಗವಾದ ಮತ್ತು ಸಮರ್ಥವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸುತ್ತೀರಿ.